(moved to a new thread) On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote: > I wrote: >> ... I still see the problematic GRANT taking ~250ms, compared >> to 5ms in v15. roles_is_member_of is clearly on the hook for that. > > Ah: looks like that is mainly the fault of the list_append_unique_oid > calls in roles_is_member_of. That's also an O(N^2) cost of course, > though with a much smaller constant factor. > > I don't think we have any really cheap way to de-duplicate the role > OIDs, especially seeing that it has to be done on-the-fly within the > collection loop, and the order of roles_list is at least potentially > interesting. Not sure how to make further progress without a lot of > work. I looked at this one again because I suspect these "thousands of roles" cases are going to continue to appear. Specifically, I tried to convert the cached roles lists to hash tables to avoid the list_member_oid linear searches. That actually was pretty easy to do. The most complicated part is juggling a couple of lists to keep track of the roles we need to iterate over in roles_is_member_of(). AFAICT the only catch is that select_best_grantor() seems to depend on the ordering of roles_list so that it prefers a "closer" role. To deal with that, I added a "depth" field to the entry struct that can be used as a tiebreaker. I'm not certain that this is good enough, though. As shown in the attached work-in-progress patch, this actually ends up removing more code than it adds, and it seems to provide similar results to HEAD (using the benchmark from the previous thread [0]). I intend to test it with many more roles to see if it's better in more extreme cases. [0] https://postgr.es/m/341186.1711037256%40sss.pgh.pa.us -- Nathan Bossart Amazon Web Services: https://aws.amazon.com